The default move when an enterprise team is asked to "do something with AI" is to add a feature. A summarise button. A chat panel. A draft-for-me icon next to the existing rich-text editor. The work ships, the press release gets written, the demo plays, and three quarters later someone in finance asks why the GPU bill has tripled and the conversion needle has not moved. The team gets defensive. The CFO gets sceptical. The next round of investment is harder to get.
Almost every enterprise AI project we have been brought in to fix has shared this shape. The diagnosis is rarely about the model, the prompt, or the eval harness — although those are often broken too. The diagnosis is that the team built AI as a feature when the opportunity was to build it as a mechanism.
The difference, plainly
A feature is something a user clicks on. It does a thing they could otherwise do themselves, slightly faster. It lives on a page, in a panel, as a button. It is a unit of product surface.
A mechanism is part of how the system runs. It does work the team could not do at all without it — usually because the volume or the speed or the personalisation makes it impossible by hand. It does not necessarily have a UI. It runs behind the surfaces the user already uses.
The summarise button on top of a support ticket is a feature. The system that watches every ticket as it arrives, classifies it, routes it to the right specialist, drafts a reply, and queues it for review, is a mechanism. The feature is incremental. The mechanism reshapes what the team can take on at all.
Why most teams build features
Three reasons, in roughly this order.
Features are easier to scope. A button has a clear surface area. A mechanism has tentacles into the data layer, the operations layer, sometimes the regulatory perimeter. The scoping conversation for a feature fits in an hour. The scoping conversation for a mechanism takes three meetings and surfaces the parts of the org chart no one wanted to look at.
Features demo well. A button is a story you can tell in a board meeting in 90 seconds. A mechanism is a story that requires the audience to follow process changes that span six job families. The first lands. The second exhausts.
Features earn promotions. Shipping a visible thing is rewarded by the org. Building infrastructure that quietly does work the org used to throw bodies at is harder to make legible inside an annual review cycle. The incentives push the team toward the wrong shape of work.
What it looks like to build the mechanism instead
A worked example. A leading Indian fashion marketplace sends millions of CRM communications a day. The legacy operating model: a creative team produces one campaign template per send, gets sign-off, ships it across a segment cut by the broadest demographics available. The bottleneck is not technology. It is creative bandwidth.
The feature version of AI for this team would be: add a "generate variant" button next to the existing creative tool. Useful — the creative team uses it to ship a second variant per send instead of one. Throughput goes up modestly. The bottleneck moves but doesn't break.
The mechanism version is different. A creative automation layer reads the segment, the channel, the brand guidelines, and the brief, and produces a thousand variants — one per segment-channel-context cell — to the brand's standard, with no human in the per-variant loop. The creative team's job changes from writing each variant to setting the rules the variants are generated against. The bottleneck is not moved. It is removed.
This is what we built. The output is not a feature on top of the existing tool. The output is a different operating model for the team, and the AI sits inside it as the part that makes the new model possible at all.
The feature is incremental. The mechanism reshapes what the team can take on at all.
The economic argument
The reason this matters is unit economics. An AI feature has linear or super-linear cost — every click is a model call, every model call has a price. The cost goes up with usage. The marginal value usually doesn't, because the feature is doing a thing the user could have done anyway, slightly faster.
An AI mechanism has a different cost shape. The cost still scales with usage, but the value scales faster than the cost — because the mechanism is doing work the team could not have done at all. Each marginal unit of cost buys an output that didn't have a manual alternative.
The result, three years in: feature teams are arguing for budget against rising GPU bills and stagnant metrics. Mechanism teams are pointing at a unit cost per output that has dropped 80% while output volume has gone up an order of magnitude. The arithmetic decides the next funding round.
How to tell which one you are building
A diagnostic. Ask your team these four questions about the AI project on the roadmap.
- If you removed it tomorrow, what would the team do differently? If the answer is "the same things, slightly slower," it's a feature. If the answer is "they couldn't do their job at all in its current shape," it's a mechanism.
- Where does it live in the workflow? If it has a button somewhere, it's probably a feature. If it sits inside the data layer and runs continuously, it's probably a mechanism.
- What does the cost look like at 10× usage? If costs and value both rise 10×, it's a feature with no operating leverage. If costs rise 10× and value rises 30× or 100×, it's a mechanism.
- Who owns it on the org chart? Features sit inside a single product team. Mechanisms cross teams — usually operations, product, data, and one regulatory or compliance function.
The studios still building features are okay, for now
It is worth being clear that there is nothing wrong with shipping AI features. They land, they sometimes help, they keep the team employed for the cycle. The risk is medium-term, not immediate. In a market where most competitors are also shipping features, you do not get punished for doing the same.
The punishment comes when one competitor stops shipping features and ships a mechanism. They get a step-change in unit economics, and the rest of the market is suddenly competing against pricing that doesn't make sense. By the time the laggards catch up, two cycles have passed and the customer base has moved.
What to do, if you're rebuilding the project
One last thing. If you have an existing AI project that is shipping as a feature and you suspect it should have been a mechanism, the rebuild is rarely free. It is, however, almost always cheaper than continuing to operate the feature version. Three moves we have seen work:
Map the workflow, not the page. The product surface is the wrong unit of analysis. Map the entire workflow the AI is meant to serve. The mechanism is the version of the work that runs the workflow, not the version that lives on one page inside it.
Find the unmovable bottleneck. Talk to the operators. The bottleneck is rarely where the dashboards say it is. The mechanism's job is to dissolve the unmovable bottleneck, not optimise the visible one.
Pick the smallest mechanism that pays. Don't try to ship the cathedral. The first mechanism should be narrow enough to ship in eight weeks and produce a result the operator can show their boss. Compounding starts there.
Closing
The AI conversation in 2026 is increasingly bifurcating. The teams building features are running out of unit-economics room. The teams building mechanisms are quietly compounding. The visible thing on the surface is the same — both sides are "doing AI." The thing underneath is not the same, and the market will sort them in the next two years.
Build the mechanism. The feature can wait.